Document a repair for each diagnostic in the constable skill - #43

An agent that reads a diagnostic needs the recovery step, not only the
rule that the code broke. The skill described two of the nine analyzers
and gave no repair for either, so the agent had to read the analyzer
source or guess, and it never learned that constable also reports method
placement, test testify use, complexity, unchecked errors, missing sum
type cases, and nil flows.

Add a repair subsection per analyzer. Each one lists the message text
that the agent will see, so the agent can match the message to the
repair, and then states the repair:

- nonmutating: copy the data or return a new value; delete the directive
  only when the contract is wrong, and never reassign the parameter to
  hide the message. The message names the origin kind, and the writes
  that count are in the contract section below it.
- methodical: run `-fix`, which moves and orders the methods, and which
  files it skips. Move the method by hand when the fix skips it.
- predicates: move the operand into a function; a variable does not
  satisfy the analyzer.
- testify: `assert` replaces a call that continues the test, and
  `require` replaces a call that stops it.
- complexity: extract branches, and state the count so the agent can
  predict the next diagnostic.
- errcheck, sumtype, testifylint, nilaway: a table of message patterns
  and repairs, plus the NilAway scope flags and the `//nolint:nilaway`
  suppression.

Also record the failure exit status, because an agent that sees
`analysis skipped due to errors in package` must repair the build before
it reads any diagnostic. Update the description to say that the skill
covers the analyzers and their repairs.

Change-Id: Iedb61f32dd80f4c5dbf1368768d68d25e5152b3c

The step told the agent to install `constable@latest`, which can leave a
version that differs from the one the repository uses: the hook builds
the working tree, and CI installs the release that the repository pins.
The skill now assumes that the command is on the PATH, as the hook and CI
provide it, and it starts at the invocation that the agent must run.

Change-Id: Ie5dac101271d677d33833bc2bdd48e97591a9285

The complexity advice said only to extract branches until the count is at
or below the limit. An agent can satisfy that rule at any seam: cut the
function where the count drops, name the piece after the steps it takes,
and leave the reader with two lists of steps and no rule.

Add the test that separates a branch worth extracting from a seam that
only moves code: the new function needs a name from the problem domain,
such as `isOverdue` or `hasOpenInvoice`. A name that restates the steps,
such as `checkFlagsAndReturnTwo`, does not help the reader, and a branch
that admits only that kind of name is not a good candidate. The agent then
splits the function somewhere else, or raises the limit when the function
is one coherent rule.

State that `-complexity.limit` applies to the whole run, so the agent does
not read the earlier sentence as a per-function setting.

Change-Id: Icb767816eac9926bcad29f8e6fb656fcc1e0d413